Usually a team defines an encoding that is used for all files of a project. Sometimes there is more than one encoding, if either the project demands some specific encoding (e.g. in XML files) or a specification demands it (in the case of Java properties files).

Since the current version of Maven lacks convenient support for some encoding problems, a tool that ensures that specific files are copied with the right encoding is quite handy.

Our Recode Maven Plugin is developed for this simple task.

All code in any code-base should look like a single person typed it, no matter how many people contributed.

Rick Waldron

The reason for having one style for all written code is, that it is easier to feel home for each member of the team and concentrate on the job.

Arguments over style are pointless. There should be a style guide, and you should follow it.

Rebecca Murphey. Principles of Writing Consistent, Idiomatic JavaScript

It is also the only way to auto-format it. Auto-formatting releases the burden of manually indenting and typing spaces at the right places. It also helps you to compare changes before committing code to your favourite SCM tool.

I prefer auto-formatting over manual formatting although there are deficiencies: you cannot indent a section of your code in a way that makes it more readable. If the formatter is missing a format feature, you have to live with less readable code. But the formatters catch up quickly and not having to worry about manually formatting code is more productive and fun in my way of writing code.

Auto-formatting is one thing. Having elements in an XML file, like Maven's pom.xml, there is more to it than aligning elements and attributes. The elements should be presented in the same order. Especially for larger POM files this makes it easier to find relevant parts as the properties or dependencies. Unfortunately for this goal, the XML schema provided by the Maven team is quite lax. Laxness has its advantages, especially for casual users or small teams, but with larger teams, where you want to make things easier by providing less freedom of choice (less freedom is in some areas a surprisingly good thing), a strict XML schema is more productive. Therefore we created, based on Maven's original XML schema a strict one. Now every element is expected at one place and this expectation can be tested automatically. On writing the stict POM XML schema we guided ourselves by the documented order as shown on the Maven web site.

If you are interested, you may download and use this strict POM from our maven-strict-pom project page.

Unfortunately the strict XML schema does only warn you on validating the POM file, if the ordering does not meet the strict XML schema. So you have to fix the announced validation error in the pom.xml manually.

What goes beyond the strict schema we offer in our project is what Maven SortPom Plugin does. It allows to sort your POM according to predefined rules.

The following configuration meet the constraints defined in our strict POM schema:

<plugin>
  <groupId>com.google.code.sortpom</groupId>
  <artifactId>maven-sortpom-plugin</artifactId>
  <version>2.0.0</version>
  <dependencies>
    <dependency>
      <groupId>de.smartics.config</groupId>
      <artifactId>maven-strict-pom</artifactId>
      <version>1.1.0</version>
    </dependency>
  </dependencies>
  <configuration>
    <expandEmptyElements>false</expandEmptyElements>
    <keepBlankLines>true</keepBlankLines>
    <createBackupFile>true</createBackupFile>
    <sortOrderFile>strict-pom.xml</sortOrderFile>
  </configuration>
</plugin>

Unfortunately, if you are concerned with whitespace settings (like inside of description elements), the plugin does not preserve these spaces. But otherwise this fine plugin enables you to do auto formatting with your POM files!

Recently I tried to create DDLs with the Hibernate 3 Maven Plugin. Since I was using Hibernate 4 this did not work. Since Hibernate 4 provides support for DDL generation, the integration into a Maven plugin proofed not to be very difficult.

I wrote a quick-and-simple Hibernate 4 Maven Plugin that provides just the DDL generation I needed. Please consider it not to be a replacement for the fine hibernate3-maven-plugin! But if DDL creation is all you need for Hibernate 4, the Hibernate 4 Maven Plugin might come handy to you.

The following POM fragment shows everything the plugin is currently (version 0.1.1) capable of:

<plugin>
  <groupId>de.smartics.maven.plugin</groupId>
  <artifactId>hibernate4-maven-plugin</artifactId>
  <version>0.1.1</version>
  <executions>
    <execution>
      <id>export</id>
      <goals>
        <goal>hbm2ddl</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <unitName>jpa-unitname</unitName>
  </configuration>
</plugin>

If you pass SNAPSHOT versions of your software around, it is sometimes difficult to derive the source code version from the artifact. Usually you should produce releases (maybe alpha or beta releases), so that that the source code is tagged in your SCM. But sometimes this does, for whatever reason, not work. In these cases it would be nice, if the SCM revision number would be written to the JAR manifest automatically. This would make fiddling out the source code for a given artifact a brise.

The Buildmetadata Maven Plugin (previously called Maven Buildmetadata Plugin, but renamed due to the naming convention of the Maven team that all plugins following the naming scheme maven-xyz-plugin are developed by the them) does exactly that. If your are building JAR/EAR/WAR files with Maven the plugin fetches the version number from an SVN server (currently the only supported SCM system) and writes it to the manifest file.

Implementation-SCM-Revision-Date: 16.07.2010 18:12:57
Implementation-SCM-Revision-Number: 4223

The build.properties file, also stored in the META-INF folder, reveals this and additional information:

build.scmLocallyModified=false
build.scmRevision.date=26.08.2012 12\:10\:03
build.scmRevision.id=4223
build.scmRevision.url=scm\:svn\:https\://server/svn/product/trunk

The plugin checks, if the build uses locally modified (build.scmLocallyModified) files. If there a locally modified files, which usually indicates that the build was made on a developer station, these files are listed by their names.

This makes the task of tracking the source code by examining a binary artifact an instant success.

The buildmetadata-plugin also collects additional information like the machine the artifact has been built on, together with the operating system, Java and Maven version. Any environment information can be added to the meta data of the generated artifact. The plugin also supports a simple hook to access further information from a remote system.

As an add-on there is a report plugin that displays the build information on your Maven site. Look at the plugin's build report for an example.

So if you are looking for a tool to add information to the meta data of your artifacts, the chances are good that the Buildmetadata Maven Plugin will help you with your task.